回到本系列的主題:程式不是會動就好
在安全性上的設計,更是完全的貼切這個主題。如果設計出在裸奔的網站(請參考黑大的文章),就算網站上的功能可以正常運作,但千瘡百孔的網站,可能淪為人家的玩物或是提款機。
SQL injection的問題,在前幾年掀起了不少次旋風,甚至包括現在可能還有一堆網站有著同樣的問題,要命的是,根本不需要到駭客等級,就可以把有SQL injection問題的網站搞掛。一個程式設計師寫出來的程式,最要不得的就是有SQL injection的問題,我個人認為那是程式設計師不夠專業,甚至不夠格的表現。這不需要多高深的技巧跟學問,要嘛就是程式設計師偷懶,要嘛就是還不夠專業。
這篇文章簡介一下,SQL injection的基本原理,以及基本的防範措施。
[如何提升系統品質]系列文章連結
回到之前重構系列的第一篇文章:[如何提升系統品質-Day2]重構– UI, Business logic, Data access概念分開,以這篇文章的例子來說明,不好的設計,SQL injection會怎麼發生。
畫面
需求
當輸入的帳號密碼,在資料庫中有吻合的資料,代表帳號密碼是對的。(再強調一次,一般設計驗證密碼的部分,應該是透過畫面上輸入密碼的值進行hash,再與資料庫中該帳號所對應hash完的密碼比對,以保障密碼不是以明文存在於資料庫中,確保密碼無法被還原)
直覺設計且造成SQL injection問題的程式碼
protected void Verify_Click(object sender, EventArgs e)
{
string connectionString = @"myConnectionString";
int count;
using (SqlConnection cn = new SqlConnection(connectionString))
{
cn.Open();
string sqlStatement = @"Select Count(1) From SomeTable Where ID= '" + this.Id.Text + "' AND Password= '" + this.Password.Text + "'";
SqlCommand sqlCommand = new SqlCommand(sqlStatement, cn);
count = (int)sqlCommand.ExecuteScalar();
}
this.Result.Text = (count > 0) ? "Pass" : "帳號或密碼錯誤";
}
這樣的程式碼會有什麼問題? 問題可大了! 假設我是壞人,知道或猜測這功能的SQL是這樣串的(大部分功能都很好猜的,猜錯了也不會被咬),那麼我只要在畫面上的Id,隨便輸入個值,接著在密碼的部分,輸入**' OR 1=1; --**
這時候,這一支聰明的功能就可以把完整的SQL statement組出來,變成Select Count(1) From SomeTable Where ID= '隨便輸入' AND Password ='' OR 1=1; --
輸入這樣的值代表什麼,代表所有畫面上的輸入值都無所謂,因為1=1恆等式一定會成立,且前面的condition為OR,所以可以把前面的where condition都忽略掉。後面再補上個分號,代表這一個SQL子句已經結束,最後再補上--,代表後面的sql為註解。
就這樣,最基本的SQL injection就成功了。是的,這個網站在裸奔了。
如果你以為,只有登入頁面會存在這樣的問題,或是這樣的問題影響不大,那就大錯特錯了。通常會寫出這樣程式的人,如果又都是自己設計,那洞就不只一個。首先,DB的存取帳號,可能就是預設的sa或admin,也就是權限開到最大。這時候的SQL injection要進DB做事,就跟進自己家廚房一樣,例如:
Select Count(1) From SomeTable Where ID= '隨便輸入' AND Password ='' OR 1=1; DROP DATABASE pubs --
恭喜你,你DB中的pubs這個DataBase就被Drop掉了。
駭客高興的話,也可以針對sysobjects跟syscolumns來瞭解你DB中有哪些table, 欄位,再比對一下網頁的資料,接著透過Update的語法,把相關的欄位資料加入一些html tag或惡意的程式碼,進而引發從SQL injection觸發的Cross-site Scripting(XSS攻擊),常見的結果就是連到那一頁時,可能被導到別頁,或是XX政府網站上被掛上特殊的國旗,再來就是莫名其妙的個資外洩。
這些情況充斥在我們的生活中,這一切的原罪,都是因為程式設計師的偷懶或不專業。
除了上述的例子,還可以怎麼瞭解SQL的組成?以ASP.NET來說,一樣,通常會寫出那樣有問題的程式,web.config可能也沒有設定custom error頁面,所以當程式出錯時,IIS就大剌剌的幫你把程式錯誤的資訊show在網頁上(就是黃頁的那個),要讓錯誤資訊是掛在SQL statement執行錯誤,是一件再簡單不過的事。所以,要瞭解該網頁的輸入和對應SQL的組成,根本不需要駭客等級就可以做。瞭解之後,要啟動SQL injection,也就只是易如反掌的事。
如何避免SQL injection
簡單的說,過濾輸入值。
但,攻擊手法相當多種,要過濾的字元組合可能一個都漏不得,所以自己設定黑名單來進行過濾,是一件非不得以才做的事。如果是用ASP.NET寫,那所有人的強烈建議,就是使用Parameters。
Parameter的用法相當簡單,這也是為什麼我前面會說,寫出SQL injection問題的程式碼,是一種偷懶的行為。
protected void Verify_Click(object sender, EventArgs e)
{
string connectionString = @"myConnectionString";
var id = this.Id.Text;
var password = this.Password.Text;
int count;
using (SqlConnection cn = new SqlConnection(connectionString))
{
cn.Open();
string sqlStatement = @"Select Count(1) From SomeTable Where ID= @id AND Password= @password";
SqlCommand sqlCommand = new SqlCommand(sqlStatement, cn);
////定義parameter型別
sqlCommand.Parameters.Add("@id", SqlDbType.VarBinary);
sqlCommand.Parameters["@id"].Value = id;
////讓ADO.NET自行判斷型別轉換
sqlCommand.Parameters.AddWithValue("@password", password);
count = (int)sqlCommand.ExecuteScalar();
}
this.Result.Text = (count > 0) ? "Pass" : "帳號或密碼錯誤";
}
透過使用parameter,在SqlCommand執行時,會自動過濾掉可能造成問題的字元,並拋出對應的。
另外,SQL injection並不只會發生在where condition,也有可能發生在Order by等語法中。所以只要是畫面上可能被改變的值,要串到SQL語法中,就應該使用parameter。
結論
在patterns & practices Developer Center簡單歸納出三個步驟防止SQL injection:
Step 1. Constrain input.
Step 2. Use parameters with stored procedures.
Step 3. Use parameters with dynamic SQL.
另外的補充:
1.web.config的custom error要記得打開,避免讓『使用者』看到詳細的錯誤訊息
2.權限這種東西,都是能開越小越好,包括資料庫。
3.所謂畫面可能被改變的值,可能包括了Url上的QueryString,post過來的表單資料,甚至於cookie內容假造。
Reference
1.SqlCommand.Parameters 屬性
2.技巧和訣竅:防範SQL注入攻擊
3.SQL Injection(資料隱碼)的源由與防範之道
4.你的網站正在裸奔嗎?
5.驚見SQL Injection攻擊大海嘯-LizaMoon
6.游擊式的SQL Injection攻擊
7.How To: Protect From SQL Injection in ASP.NET
8.CustomError 類別
檢查輸入的字串中是否有 ' OR ' 的關鍵字,如有reject
黑名單的作法,是逼不得以的。自己定義過濾名單,還是可能有不少漏洞。就像上面的例子,不需要OR 1=1,也可以直接用;Drop 他想要的table --等等語法。
所以強烈建議用parameter (如果有支援的話啦),因為如果有安全問題的話,全世界一起有安全問題。而且即使有安全問題,微軟也會在第一時間修復,或是出一個workaround。這才是最大的保障。